<html>
<head><meta charset="utf-8"><title>Name resolution librarification · t-compiler · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/index.html">t-compiler</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html">Name resolution librarification</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="172040579"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172040579" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172040579">(Jul 30 2019 at 14:06)</a>:</h4>
<p>In rust-analyzer, we need to do name resolution. Our current support is pretty limited (main limitation: items inside blocks don't participate in name res at all), and I wonder what is the best path forward for improving this...</p>
<p>Realistically, I think we have no one who can, at this point, spearhead the real name resolution librarification effort. So, for the time being, it seems best if rust-analyzer continues with its own thing. I wonder, however, how to make this "own thing" useful long-term.</p>
<p><span class="user-mention" data-user-id="123856">@Vadim Petrochenkov</span> do you have any suggestions as to what is the best path forward here? Should we, at rust-analyzer, just write something that works? Should we perhaps try some specific experimental approaches which are hard to use in current rustc? Should we put special effort into writing design documents/specifications?</p>
<p>As a remainder, the main thing we need to do differently for IDEs is to have the ability to <em>not</em> look into function bodies for name resolution. This technically doesn't work in Rust in edge cases (b/c #[macro_export] and impls are global), but this is a very important optimization for IDEs, so I'm betting on separate code-paths for rustc and rust-analyzer here, and future language-level tweaks to make item bodies more isolated.</p>



<a name="172041331"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172041331" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172041331">(Jul 30 2019 at 14:14)</a>:</h4>
<p>Why can't IDEs look into function bodies? I would sort of expect that you have to parse the body to find the end anyway, at which point you're not really gaining anything by ignoring struct/enum/etc definitions</p>



<a name="172041392"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172041392" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172041392">(Jul 30 2019 at 14:14)</a>:</h4>
<p>OTOH, I believe current rules mean that in order to find the definition of a struct/enum it's fine to ignore function bodies unless it's the current function because there's no way to export them</p>



<a name="172041651"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172041651" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172041651">(Jul 30 2019 at 14:17)</a>:</h4>
<p><span class="user-mention" data-user-id="116122">@simulacrum</span> almost all code is in bodies. If we ignore bodies, we'll get significantly less data to process.  You don't even need to parse bodies, because counting <code>{}</code> would be enough</p>



<a name="172041787"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172041787" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172041787">(Jul 30 2019 at 14:18)</a>:</h4>
<p>Hm, I guess I sort of presumed counting <code>{}</code> would be approximately as slow as fast-parsing for e.g. keywords <code>struct</code>/<code>union</code> etc</p>



<a name="172041836"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172041836" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172041836">(Jul 30 2019 at 14:18)</a>:</h4>
<blockquote>
<p>OTOH, I believe current rules mean that in order to find the definition of a struct/enum it's fine to ignore function bodies unless it's the current function because there's no way to export them</p>
</blockquote>
<p>macros break that <span aria-label="sob" class="emoji emoji-1f62d" role="img" title="sob">:sob:</span> </p>
<p><a href="https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2018&amp;gist=7ebc99813e42c705a66b7705d2165a7c" target="_blank" title="https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2018&amp;gist=7ebc99813e42c705a66b7705d2165a7c">https://play.rust-lang.org/?version=stable&amp;mode=debug&amp;edition=2018&amp;gist=7ebc99813e42c705a66b7705d2165a7c</a></p>



<a name="172041960"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172041960" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172041960">(Jul 30 2019 at 14:20)</a>:</h4>
<p>I would expect current resolution to be able to work with a partial view of the world -- e.g. <code>everybody_loops</code> applied to functions essentially</p>



<a name="172041980"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172041980" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172041980">(Jul 30 2019 at 14:20)</a>:</h4>
<p>Is that not the case?</p>



<a name="172042147"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172042147" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172042147">(Jul 30 2019 at 14:22)</a>:</h4>
<p>It could work that way, yeah. And that's basically how rust-analyzer now works. But, when you actually look into the body of the current function, you need to glue together results of local resolution and global resolution. This is the bit that is missing from rust-analyzer.</p>



<a name="172042273"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172042273" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172042273">(Jul 30 2019 at 14:22)</a>:</h4>
<p>Like, I think it's realitevely straightforward to <em>just</em> do this, and we can add this to rust-analyzer. But I feel that's the case where a bit of up-front design can be helpful</p>



<a name="172042625"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172042625" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172042625">(Jul 30 2019 at 14:26)</a>:</h4>
<p>Sure, yeah -- maybe a simple bit would be to make rustc's resolver a bit more generic so it can be used as a library by rust-analyzer more easily (without needing to port to libsyntax types and such)</p>



<a name="172042697"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172042697" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172042697">(Jul 30 2019 at 14:26)</a>:</h4>
<p>I would sort of expect that even rustc's analyzer wants to be able to do incremental resolution based (just not today, since incremental comp. starts after it IIRC)</p>



<a name="172042910"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172042910" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172042910">(Jul 30 2019 at 14:28)</a>:</h4>
<blockquote>
<p>maybe a simple bit would be to make rustc's resolver a bit more generic so it can be used as a library by rust-analyzer more easily</p>
</blockquote>
<p>I fear that this <em>simple</em> bit is on order of half a year of work full time. We definitely <em>should</em> do this eventually, but I am not sure that right now is the best time, given that, for example, there's unfinished chalk work</p>



<a name="172042982"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172042982" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172042982">(Jul 30 2019 at 14:29)</a>:</h4>
<p>Sure, yeah, "simple" in terms of describing it I guess :)</p>



<a name="172043021"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172043021" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172043021">(Jul 30 2019 at 14:29)</a>:</h4>
<p>Chalk seems orthogonal to this though? i.e. trait-related vs. name resolution</p>



<a name="172043095"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172043095" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172043095">(Jul 30 2019 at 14:30)</a>:</h4>
<p>But yeah, just sharing the nameres code would be ideal. However, it took me a long time to do this for lexer (<a href="https://github.com/rust-lang/rust/issues/59706" target="_blank" title="https://github.com/rust-lang/rust/issues/59706">#59706</a>), and lexer is like infinitely more simple than name res</p>



<a name="172043171"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172043171" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172043171">(Jul 30 2019 at 14:30)</a>:</h4>
<p><span class="user-mention" data-user-id="116122">@simulacrum</span> yeah, chalk is orthogonal but I am not sure that having many parallel (pun intended) efforts is good</p>



<a name="172043305"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172043305" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172043305">(Jul 30 2019 at 14:32)</a>:</h4>
<p>That's true. name resolution's complexity includes HIR and AST and such so I agree it is much harder to do (presumably)</p>



<a name="172043358"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172043358" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172043358">(Jul 30 2019 at 14:32)</a>:</h4>
<p>Though, I <em>think</em> I can maybe drive this effort, after I finish the remainig bits of lexer.... I don't know a lot about name res, but I'd like to learn more</p>



<a name="172043429"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172043429" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172043429">(Jul 30 2019 at 14:33)</a>:</h4>
<p>The main complication I think is how tightly coupled name resolution is to the compiler in terms of driving macro expansion, etc.</p>



<a name="172043443"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172043443" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> simulacrum <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172043443">(Jul 30 2019 at 14:33)</a>:</h4>
<p>It wants to know a lot</p>



<a name="172043581"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/131828-t-compiler/topic/Name%20resolution%20librarification/near/172043581" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matklad <a href="https://rust-lang.github.io/zulip_archive/stream/131828-t-compiler/topic/Name.20resolution.20librarification.html#172043581">(Jul 30 2019 at 14:35)</a>:</h4>
<p>Yeah: there's no clear name resolution "intermediate language", though it seems like there <em>should</em> be one (sets of names indexed by scopes and namespaces)</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>